This invention relates to network security and more particularly to the reconciliation of policy or business objectives with working information technology infrastructure. The invention may be used by any organization, group, business or individual to govern access to data, applications, hosts, data traffic, as well as anomalies, weaknesses and defects of a data network infrastructure. Embodiments of the invention relate specifically to the rules in Section 1 of Payment Card Industry Data Security Standard (PCI DSS) version 1.1, but the principles have broader application than credit card security. PCI DSS is one example of an external regulatory framework that imposes requirements on Information Technology (IT) infrastructure. It is referred to herein as an example of a broad class of similar requirements, externally imposed through regulation or business contract or internally imposed by an organization's own security standards and policies. The subject matter of this invention is a way to meet any requirement to demonstrate that a data network permits or does not permit certain classes of access, or to demonstrate that access control devices (such as firewalls) are deployed and configured along necessary access pathways.
By way of background, the Payment Card Industry Data Security Standard (PCI DSS) comprises guidelines and procedures for the collection, transmittal and storage of credit card information. The Standard contains a great deal of prescriptive detail regarding the structure and implementation of security. Due to complexity of compliance, automation is essential, and network configuration management through firewalls and routers, management policies, and configuration setup and control provide the mechanism for such compliance.
Tools are available for building models of data networks. Such tools are available commercially from the present assignee RedSeal Systems of San Mateo, Calif. and Cisco Systems of San Jose, Calif. It is assumed for this invention that the model of the data network already exists and can be queried to show whether access from any point to any other point is permitted (including details of the protocols and ports that are allowed or blocked). The goal is to compare the data model with a collection of statements (“access specifications”) that indicate what should or should not be permitted, and then indicate non-compliance if any access is found that is either undocumented or explicitly forbidden.
There are a variety of statement types that can be applied, including at least the following types:
1. Access matching an access specification is acceptable (white-list rules)
2. Access matching an access specification is not acceptable (negative rules)
3. Access matching an access specification must be present (positive rules)
4. Access matching an access specification is the only permitted access of that type (exclusive rules)
5. Overriding access specifications of any of the prior types.
(Strictly, the fifth type, commonly called “exceptions”, is a convenience feature, since logically speaking all documentation requirements could be met with the other types. However, in real audit and compliance situations, it is common to write rules of the abstract form “none of the following, except for special case x”, or “all of the following, except special cases y and z”.)
Prior approaches to the assessment of policy generally lacked either a flexible range of access specifiers or a complete and automated model of the network environment that can provide details of which access is allowed before the user has to specify any rules. An approach which only takes statements from the user first, then tests those statements and only those statements, is not a reliable way to ensure that the whole environment meets the desired objectives. What is needed is a tool that makes it easier for a network operator or an operator to control and evaluate the security of the network and more particularly to verify compliance with network policy standards.